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La presente invention concerne une station de programmation §laborant un 
programme utilisant un langage unique, hierarchis6 et oriente objet pour 
programmer une application d'automatisme et un equipement d'automatisme 
utilisant un programme 6labore par une telle station de programmation. 

5 Une station de programmation d6signe ci-apr6s un equipement 

informatique, notamment un ordinateur personnel de type PC, connectable d un 
equipement d'automatisme. Un equipement d'automatisme designe ci-apres un 
automate programmable, une station de controle/commande, une commande 
num§rique ou tout equipement pouvant contenir et exporter un programme 

10 d'application controlant une application d'automatisme. Cette application 
d'automatisme appartient par exemple au domaine des automatismes industriels, 
des automatismes du batiment ou du controle/commande des reseaux electriques 
de distribution. 

Un tel equipement d'automatisme est compose d'une unite centrale et d'un 
15 ou plusieurs coupleurs d'entr6es-sorties connectes a des capteurs et a des 
preactionneurs de ('application d'automatisme a commander. 

L'unite centrale comprend au moins un processeur, une memoire non 

,. i. 

volatile, en general non modifiable (type ROM), ou modifiable (type EEPROM), 
contenant le programme constructed appele encore systeme Sexploitation 

20 proprietaire (proprietary operating system) exprime dans un langage specifique au 
constructeur de Pequipement d'automatisme, une m§moire vive et un gestionnaire 
des entrees/sorties, qui communiquent entre eux par un bus dit de fond de panier. 
La memoire vive ou memoire volatile (type RAM) contient, dans une premiere zone, 
le programme utilisateur et dans une deuxieme zone, les donnees, en particulier les 

25 images des etats des coupleurs d'entr6es-sorties et les constantes relatives au 
programme utilisateur. 

Le programme utilisateur, ou appele encore programme duplication, est 
charge de faire du controle ou de la commande d'une application d'automatisme au 

30 moyen d'entrees/sorties pilotees par ce programme duplication. II est elabore par 
un concepteur et est ecrit dans un ou plusieurs langages graphiques d'automatisme 
integrant notamment des schemas £ contacts (Ladder Diagram), appetes ci-apres 
langage Ladder, des diagrammes fonctionnels en sequence (Sequential Function 
Chart ou langage Grafcet), appel6s ci-apres langage SFC, des blocs fonctions 

35 (Function Block Description), appeles ci-apr6s langage FBD, ou bien dans des 
langages textuels d'automatisme de type IL (Instruction List) ou ST (Structured 
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Text). Ces langages cTautomatisme sont avantageusement conformes a la norme 
IEC1 131-3, de fa^on a faciliter la programmation par un concepteur automaticien ne 
maTtrisant pas forcement les langages informatiques. Ces langages sont utilisables 
sur des stations de programmation qui sont reliees ou non a I'equipement 
5 d'automatisme a programmer. 

A ce jour, les programmes duplication resultant de ['utilisation des 
langages graphiques d'automatisme conformes a la norme IEC1 131-3 ne peuvent 
pas etre echanges entre equipements d'automatisme de constructeurs differents 

10 ayant des programmes constructeurs reposant sur des langages constructeurs 
differents. En effet apres que le concepteur d'un automatisme ait realise le 
programme d'application dans un des langages normalises, la station de 
programmation sur lequel le concepteur travaille traduit ce programme dans le 
langage specifique du constructeur de I'equipement d'automatisme sur lequel le 

15 programme d'application a ete developpe, car il n'existe pas de format d'echanges 
standardise. 

Un premier but de I'invention est d'obtenir une station de programmation 
utilisant un langage unique, hierarchise et oriente objet editable par n'importe quel 
20 editeur pour decrire des applications d'automatisme quel que soit le langage 
graphique de fonctionnement de I'equipement d'automatisme. 

Ce but est atteint par le fait qu'une station de programmation d'une 
application d'automatisme destinee & etre executee dans un equipement 

25 d'automatisme, memorise dans une memoire interne au moins un fichier de 
grammaire contenant une grammaire de description des applications d'automatisme 
en format textuel, pour au moins un des langages graphiques d'automatisme 
(Ladder, SFC, FBD) selon un langage unique, hierarchise et oriente objet. La 
station de programmation contient egalement en memoire un ensemble d'un ou 

30 plusieurs fichiers de description, chaque fichier de description d6crivant une partie 
de Papplication d'automatisme et etant exprime dans le langage unique, hierarchise 
et oriente objet. 

Selon une caracteristique, le langage unique, hierarchise et oriente objet 
est le langage XML (extended Markup Language). 
35 Selon une autre particularite, I'ensemble des fichiers de description de 

I'application contient un fichier de description du programme d'application, un fichier 
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de description des entrees-sorties de I'application et un fichier de description des 
donnees de I'application. 

Selon une autre particularity un fichier de grammaire decrit une application 
en langage Ladder en definissant les differents elements du langage Ladder 
5 comme des objets, chacun de ces elements comprenant des attributs soit sous 
forme d'objets, de param&res, de variables ou de textes et constituant des 
informations memorisees dans la m6moire interne de la station de programmation 
et representables sous forme d'arborescence. Les differents elements du langage 
Ladder comprennent un contact, un lien horizontal, un lien vertical, une bobine, un 

10 court-circuit, une cellule vide, un appel de bloc fonction, une expression FFB, un 
bloc de comparaison, un bloc d'operations arithmetiques. 

Selon une autre particularite, un fichier de grammaire decrit une application 
en langage SFC en definissant comme des objets les differents elements du 
langage SFC, a savoir une etape, une transition, un saut, un lien entre graphe, un 

15 commentaire, les coordonnees graphiques des differents elements de type saut, 
etape ou transition etant definies par un objet de type position definissant les 
coordonnees de position de I'objet respectif dans la grille de lignes et de colonnes 
de representation du graphique de fobjet sur des moyens de visualisation.de la 
station de programmation. 

20 Selon une autre particularite, un fichier grammaire decrit une application en 

langage FBD en definissant les differents elements du langage FBD comme des 
objets. Les differents elements du langage FBD comprennent des blocs fonctions, 
des boites de texte, des liens entre blocs, des instructions de saut, des labels et 
des commentaires. 

25 

Un autre but est de proposer une station de programmation permettant 
Timportation ou Pexportation dans le langage unique duplications d'automatisme 
existantes en langage graphique d'automatisme (Ladder, SFC, FBD). 

Ce but est atteint par le fait que la station de programmation incorpore, 

30 dans une memoire non volatile, un gestionnaire XML Hndlr dialoguant par des 
notifications, d'une part avec un module de gestion de I'arborescence 
representative de Papplication d'automatisme exprim6e. dans le langage unique, 
hierarchis§ et oriente objet et d'autre part avec une pluralite de gerants de bases de 
donnees, chaque g£rant etant spgcifique a une partie de ('application 

35 d'automatisme memorisee dans une des bases de donnees. 
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Un dernier but de invention est de proposer un equipement d'automatisme 
utilisant un langage unique pour decrire une application d'automatisme quel que soit 
le langage constructeur utilise sur I'equipement d'automatisme. 

Ce but est atteint par un equipement d'automatisme capable d'executer 
une application d'automatisme et caracterise en ce qu'il comprend des moyens de 
memorisation pour memoriser un ensemble d'un ou plusieurs fichiers de description 
de I'application d'automatisme exprimes dans un langage unique, hierarchise et 
oriente objet. L'equipement d'automatisme comporte egalement des moyens de 
traduction permettant de convertir les fichiers de description dans un langage 
binaire executable par l'equipement d'automatisme. 

Selon une caracteristique, le langage unique, hierarchise et oriente objet 
est le langage XML (extended Markup Language) et le ou les fichiers de description 
respectent une des grammaires de traduction en langage XML d'un ou plusieurs 
langages graphiques d'automatisme parmi le langage Ladder, le langage SFC et le 
langage FBD. 

Selon une autre caracteristique, I'equipement d'automatisme comporte des 
moyens de verifier que, selon le langage graphique d'automatisme utilise, la 
description de I'application en langage XML satisfait la grammaire de description du 
langage graphique d'automatisme utilise. 

La grammaire XML proposee permet de definir un format textuel 
d'echange pour les cinq langages graphiques ou textuels (LD, SFC, FBD, IL, ST) 
conformes a la norme IEC1 131-3. Du fait que les fichiers sont en ASCII, ils sont 
editables par des editeurs de texte standard (Notepad, ...) sur n'importe quelle 
station de programmation reliee ou non a l'equipement d'automatisme. 

Les donnees de I'application d'automatisme vont aussi etre decrites en 
langage XML et pourront ainsi etre facilement importees ou exportees vers 
differents logiciels tiers (CAO electrique, Supervision, ...). 

Les fichiers en langage XML pourront par ailleurs etre transformes vers 
d'autres fichiers en langage XML ayant une grammaire differente, grace au 
mecanisme des feuilles de style (XSLT : extensible Stylesheet Language 
Transformation). II sera par exemple tres facile de faire une passerelle entre les 
donnees d'une application d'automatisme et un logiciel tableur comme EXCEL de 

Microsoft Corporation. 

Les parties d'applications generees en langage XML pourront etre 
visualisees par des utilitaires de recherche, visualisation, edition (browsers) de la 
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toile WEB (Internet Explorer par exemple), ceux-ci incluant de base des afficheurs 
de XML. C'est un autre avantage de la solution proposee que d'offrir une 
grammaire formelle pour echanger des programmes et des donnees d'une 
application d'automatisme. 

5 

D'autres particularity et avantages de la pr6sente invention apparaitront 
plus clairement a la lecture de la description ci-apres faite en reference aux dessins 
annexes dans lesquels : 

- la figure 1 repr6sente une vue schematique d'une station de 
10 programmation 6quipee d'un gestionnaire XML pour importer ou exporter des 

fichiers de description d'une application du langage unique vers un des langages 
graphiques, 

la figure 2 montre un exemple d'organisation en memoire de la grammaire 
permettant de d6crire une application d'automatisme dans le langage unique selon 
15 Tinvention, 

- la figure 3 reprSsente un composant logiciel qui constitue un generateur 
d'index de balises pour produire des fichiers d'index, 

- la figure 4 represente une vue schematique des modules constitutifs d'un 
gestionnaire XML Hndlr permettant rimportation et ('exportation de fichiers d'un 

20 langage vers un autre. 

L'invention consiste & decrire une application d'automatisme, grace a un 
langage unique, orients objet et base sur des objets hierarchises, a partir d'une 
grammaire de ce langage qui est propre & la traduction, dans ce langage, d'un 

25 programme duplication d'automatisme ecrit dans un des langages graphiques 
conformes a la norme IEC1 131-3. Dans le mode de realisation presente, ce 
langage unique, hierarchise et oriente objet est par exemple le langage XML 
(extended Markup Language). La description est uniquement textuelle (aucune 
information binaire), elle est independante de l'impl6mentation et doit respecter les 

30 standards XML. La description XML d'une application pourra etre stockee en tout 
ou partie sous forme d'un ensemble d'un ou plusieurs fichiers de description. Ces 
fichiers pourront etre importes et/ou exportes vers des iQgiciels tiers. On attribue a 
chaque objet descriptif de Tapplication en langage XML, d'une part des balises 
(Tags) XML qui sont des mots encadr6s par des signes "inferieur" (<) et "superieur" 

35 (>) et d'autre part des attributs (de la forme nom= n valeur"). L'application entiere 
peut done etre d6crite a I'aide des balises et des attributs. Les balises sont utilisees 
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seulement pour delimiter les elements de donnees et laissent rentiere interpretation 
des donnees a I'application qui les lit. Ces balises sont generalement constitutes 
par des mots comprehensibles meme pour un utilisateur non expert dans le 
domaine. 

Habituellement, une application d'automatisme est decrite par plusieurs 
fichiers de description comportant un fichier de description du programme 
d'application, un fichier de description des entrees-sorties de I'application et un 
fichier de description des donnees de I'application. 

Une grammaire specifique a la traduction en langage XML d'une 
description d'un programme d'application en langage graphique Ladder est definie 

en annexe 1 . . 

La description en langage Ladder est structuree en reseaux de contacts : 
chaque reseau est decrit ligne par ligne du haut vers le bas. Chaque ligne est 
decrite de la gauche vers la droite. Chaque ligne commence au rail gauche (a 
gauche de la representation du reseau Ladder) et se termine sur le dernier element 
graphique decrit. Chaque ligne contient une liste d'elements graphiques standards 
du langage Ladder (langage a relais) : contacts, bobines, lien horizontal, lien 
vertical, bloc fonction .... Les coordonnees graphiques sont relatives a la position 
des objets dans la grille de lignes et de colonnes de representation d'un graphique. 

La ligne 10 de la grammaire representee a I'annexe 1, correspondant a 
une representation graphique d'une application en langage Ladder, definit qu'une 
application "LDSource" en Ladder est constitute d'un reseau Ladder (networkLD) et 
de zero a n (indique par le signe *) boTtes de texte (textBox) definies aux lignes 59 a 
61. Un reseau Ladder (networkLD) est constitue d'une ou plusieurs (indique par le 
signe +) lignes type (typeLine) et d'un lien avec zero a n blocs fonction (FBLink). Le 
lien avec au moins un bloc fonction (FBLink) est constitue comme indique ligne 50 
de I'annexe 1 de deux objets de position (objPosition) definissant par leurs 
coordonnees une position de depart correspondant a I'attribut "depuis" (from, ligne 
51) et une position d'arrivee correspondant a I'attribut "vers" (to, ligne 52). L'objet 
ligne type (typeLine) est constitue, comme indique a la ligne 1 3 de I'annexe 1 , de 
zero a n d'une combinaison des objets suivants : soit d'une ligne vide (emptyLine), 
soit au choix d'un contact (contact), d'un lien horizontal (Hlink), d'un lien vertical 
(Vlink), d'une bobine (coil), d'un contrdle (control), d'un court-circuit (shortCircuit), 
d'une cellule vide (emptyCell), d'un appel de bloc fonction (calls), d'une expression 
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FFB (FFBExpression), d'un bloc de comparison (compareBlock) et d'un bloc 
d'operation arithmetique (operateBlock). 

L'objet ligne type (typeLine) a un attribut label qui est du texte. L'objet 
contact qui est defini a la ligne 18, a pour attribut le type de contact qui definit le 
5 type contact, ouvert, ferme, montant, descendant sous forme d'enumeration 
(openContact, closedContact, Pcontact, Ncontact) et le nom de la variable de 
contact (ContactVariableName) qui est du type texte. La ligne 23 definit l'objet lien 
horizontal (HLink) qui a pour attribut un nombre des cellules (numberCell) 
traverstes par le lien horizontal (HLink). Les lignes 26 et 27 de Pannexe 1 

10 definissent l'objet bobine (coil) qui peut etre de type bobine (Coil), bobine inverse 
(notCoil), bobine de mise a un (setCoil), bobine de mise a zero (resetCoil), bobine 
de franchissement de transition (hashCoil) utilisee uniquement en association avec 
le langage SFC, bobine a front montant (Pcoil), bobine a front descendant (Ncoil) 
ainsi que le nom de la variable bobine (coilVariableName) qui est du type texte. 

15 Uobjet controle (control) definit, lignes 35 a 37, le type de commande £ saut 
(jumpCoil) ou a retour (retCoil). Uobjet court-circuit (shortCircuit) est defini ligne 38 
comme la combinaison des objets lien vertical (Vlink) et au choix un des elements 
suivants : lien horizontal (Hlink), contact, bobine (coil), appels (calls), bloc de 
comparaison (compareBlock). Un bloc appel (calls), comme defini ligne 39, contient 

20 une instance d'un objet (instanceObj), un type de parametre (typeParam) et une 
description d'appei (descriptionCall). Le type de parametre (typeParam) et la 
description d'un appel (descriptionCall) peuvent etre, comme indique par le signe 
"?", de valeurs differentes. La valeur de type de parametre est dtfinie ligne 41 
comme etant la valeur bool6enne "0" ou "1" (enEnO). La ligne 43 definit la 

25 description d'un appel (descriptionCall) comme etant constitute d'une liste d'entrees 
(inputListFBD) de bloc fonction (FBD) qui sont des listes de parametres formels et 
de paramttres effectifs (voir lignes 45 et 46) et d'une liste de sorties 
(outputListFBD) de bloc fonction (FBD). Les boites de texte sont dtfinies par la 
position de I'objet boite de texte et par ses dimensions en hauteur et en largeur. 

30 Pour des sections tcrites en langage Ladder, chaque programme 

duplication pourra etre dtcrit en utilisant la grammaire correspondante au langage 
graphique Ladder. Chaque grammaire permet de dtfinir une hierarchie entre objets 
et de reprSsenter une application sous forme d'une arborescence graphique (30) 
dans la m6moire vive de la station de programmation. 

35 Ainsi, comme on peut le voir sur Tannexe 1, la racine de I'arbre est 

constitute par Implication source (LDSource) a laquelle sont rattaches un ou 
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plusieurs fils qui sont le reseau (networkLD) et eventuellement une oil plusieurs 
boites de texte (textBox). Le reseau a un ou plusieurs fils constitues d'objets du 
type ligne (typeLine) et du type lien FB (FBLink). L'objet de type ligne (typeLine) a 
pour fils la ligne vide (emptyLine) ou un des elements suivants : contact (contact), 
lien vertical (HLink), lien horizontal (VLink), bobine (coil), commande (control), 
court-circuit (shortCircuit), appels (calls), comparaison de blocs (compareBlock), 
execution de bloc (operateBlock), expression FFB (FFBExpression). 



Une grammaire specifique a la traduction en tangage XML d'une 
10 description d'une application en langage graphique SFC est definie en annexe 2. 

La ligne 11 de la grammaire representee a I'annexe 2 d6finit que la 
description en langage SFC d'une application (SFCSource) comprend un en-tete 
(SFCHeader) et est structure en pages (SFCPage) qui correspondent aux pages 
d'ecrans affichees par Pediteur de langage SFC. L'entete (SFCHeader) a pour 

15 attribut la tache (task) et le nom du graphe (graphName). Chaque page peut 
contenir un ou plusieurs r6seaux SFC (networkSFC). Chaque reseau contient une 
liste d 'elements "objet" choisis parmi les elements graphiques standards suivants 
du langage SFC : §tape (step), saut (jump), transition (transition), lien entre etapes 
et transition (SFCLinkObject), commentaire (commentSFC), lien entre graphes 

20 (linkSFC). Les coordonnies graphiques des differents objets de type saut, etape ou 
transition sont definies par un objet de type position (objPosition) definissant la 
position de l'objet respectif (saut, etape ou transition) dans la grille en ligne / 
colonne. Un objet de type etape (step) est defini par un ou plusieurs actions dont 
les attributs sont definis lignes 23 et 24 de I'annexe 2. Les transitions sont definies 

25 egalement par des conditions de transition (transitionCondition). Les objets du type 
liens entre graphes (linkSFC) sont constitues de deux objets de position 
(objPosition) definissant par leurs coordonnees une position de depart 
correspondant a I'attribut "depuis un type d'objet" (typeObjectFrom) et une position 
d'arrivee correspondant a I'attribut "vers un type d'objet" (typeObjectTo). Chacun de 

30 ces deux attributs est choisi parmi un des objets suivants : 6tape initiate 
(initialStep), etape (step) macro etape (macroStep), etape interne (stepln), 
transition (transition, branche A (Abranch), branche P (Pbranch), jointure A (Ajoint), 
jointure P (Pjoint) et pour I'attribut "vers" egalement entre les objets precedents et 
l'objet saut (jump). 

35 La hierarchie du langage SFC est la suivante. Uarborescence a pour 

racine l'objet source (SFCSource) qui a lui-meme pour fils l'entete (SFCHeader) et 
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la page (SFCPage). La page a pour fils le rtseau (networkSFC), lequel reseau a 
pour file I'ttape (step), le saut (jump), la transition (transition), le lien objet SFC 
(SFCLinkObject), le commentaire SFC (commentSFC), le lien entre graphes SFC 
(linkSFC). 

• « ■ 

De manure similaire, une grammaire specifique d la traduction en langage 
XML d'une description d'une application en langage graphique FBD est dtfinie en 
annexe 3. 

Chaque reseau en langage FBD contient une liste d'6lements graphiques 
standards du langage FBD : bloc fonction (FFBBIock), boTte de texte (textBoxFBD), 
label (labelObject), commentaire (commentObject FBD), lien entre blocs (linkFBD) 
et instruction de saut (jumpObject). Chaque element est defini conformtment aux 
lignes 12 a 39 de Tannexe 3. Les coordonnees graphiques sont relatives a la 
position des objets dans la grille en ligne / colonne. 

La hierarchie entre objets definie dans cette grammaire est la suivante. La 
racine est constitute par la source FBD (FBDSource), laquelle est constitute d'un ou 
plusieurs reseaux FBD (networkFBD). Chaque reseau est constitue de Tun ou 
plusieurs des Elements fils suivants : le bloc (FFBBIock), la boite .de texte 
(textBoxFBD) , I'etiquette (labeLObject), le saut (jumpObject), | e commentaire 
(commentObjectFBD), le lien (linkFBD). 

Les fichiers (402, fig.2) descriptifs de la grammaire sont en format textuel 
et sont organises de la maniere suivante. Une application d'automatisme peut se 
decomposer principalement en trois parties : son programme, ses donnees et ses 
entrees/sorties. La grammaire de chacune de ces parties est decrite, selon 
Tinvention, dans un fichier de "Definition du Type de Document" (ou Document Type 
Definition) de la forme ".dtd" (par exemple : programed pour le fichier programme 
duplication , datas.dtd pour le fichier donnees, lOConf.dtd pour le fichier de 
configuration des entrtes/sorties) ou dans un fichier "Schema" de la forme ".xsd". 
Par la suite, on parlera de fichiers ".dtd" mais ils pourront etre remplacts de faq;on 
tquivalente par des fichiers ".xsd". Ainsi, lorsque la notation de type "datas .*" est 
utilisee, cela signifie qu'il s'agit d'un fichier de donnees qui peut etre de type 
"datas.dtd" ou "datas.xsd". Chacune des parties du programme duplication 
pouvant elle-meme se decomposer en sous-parties faisant elles-memes I'objet d'un 
fichier descriptif en ".dtd" (ou ".xsd"). A titre d'exemple, le fichier programme 
(program.dtd) pourra .inclure les fichiers source (LDSource.dtd, SFCSource.dtd et 
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FBDSource.dtd, comme cela est represente a la figure 2) qui contiennent les 
grammaires de differents langages graphiques d'automatisme de type schemas a 
contacts (Ladder), diagrammes fonctionnels en sequence (SFC) et blocs fonctions 
(FBD). 

Les fichiers de grammaire ".dtd" ou ".xsd" (402) sont des fichiers 
specifiques au constructeur de I'equipement d'automatisme. lis contiennent la 
description des differentes grammaires et definissent la structure des fichiers de 
description XML. Ainsi le dossier "Application" (figure 2) comprend le fichier 
(commonElements.*) qui contient les elements communs a I'application 
d'automatisme, a savoir le nom de I'application, la date de realisation de 
I'application ou de la version, le numero de version et des commentaires. Le dossier 
"Configuration" contient les fichiers de configuration respectivement des 
entrees/sorties (lOConf.*) et de la configuration logique (LogicConf.*). Les dossiers 
"Instance", "DDT", "DFB types" contiennent la description des donnees, instance, 
DDT, FB type sous forme des fichiers (datas, DDTSource.*, FBDSource.*, 
FBSource.*). Le dossier "Program" comporte les fichiers (LDSource.*, SFCSource* 
et FBDSource.*) qui contiennent respectivement la description de chaque 
grammaire respective a chaque representation graphique usuelle en matiere 
d'automatisme decrites respectivement aux annexes 1 a 3 (langage Ladder, 
langage SFC, langage FBD). Le dossier "Animation tables" contient la description 
des tables d'animation qui est constitute en partie des fichiers (commonElements.* 
et datas.*). Le dossier "Operator screens" contient les descriptions des ecrans 
d'exploitation constitutes des fichiers des elements communs (commonElements.*) 
et des donntes du fichier (datas.*). 

Ces differents fichiers de grammaire (402) definissent la structure des 
fichiers XML. Un fichier XML d'une application represente une instance de la 
grammaire definie dans le fichier ".dtd" correspondant. Les fichiers de description 
XML (401) sont eux specifiques de I'application d'automatisme consideree. Le 
principe de correspondence entre ces 2 types de fichiers est defini par la norme 
XML V1.0 conformement au modele objet du document (DOM, Document Object 
Model). Le modele objet du document DOM est un ensemble de fonctions de 
programmation (API : Application Programming Interface) standard pour manipuler 
des fichiers XML. 
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La correspondence entre les fichiers XML et les bases de donnees de 
('application est la suivante : 

Une application d'automatisme est stockee en binaire sur une station de 
programmation connectable £ un equipement d'automatisme. Cette application 
5 d'automatisme selon Part anterieur etait mise au point par I'utilisateur qui se servait 
d'un editeur (5) pour des langages graphiques IEC1 131-3, utilisant un composant 
logiciel denomme par la suite gerant (Mng1,Mng2,...) pour ranger les saisies 
utilisateurs, dans plusieurs bases de donnees : par exemple, une base de donnees 
(Db1) pour le programme duplication, une base de donn6es (Db2) pour les 

10 donnees de I'application et une base de donnees (Db3) pour la configuration des 
entrees/sorties de ('application, (Db1 ) et (Db2) etant representees sur la figure 1 . La 
description de Implication en langage XML selon Invention est complement 
independante de son implementation dans les bases de donnees constructeurs. 
Pour assurer cette ind6pendance, un composant logiciel particulier a ete d6veloppe; 

15 il constitue un genSrateur automatique d'index de balises (Tag) represente sur la 
figure 3 et est denomme ci-apres composant GenlnTag (25). 

Le composant logiciel GenlnTag (25) generateur d'index de balises doit 
etre execute pour produire des fichiers d'index (".h") qui permettent de faire la 
correspondance entre Tarborescence graphique XML (30) representative de 

20 I'application d'automatisme dans le langage de Invention et les structures des 
bases de donnees (Db1,Db2). Plus particulierement, un fichier d'index permet de 
faire la correspondance entre les nceuds de I'arborescence produite par Pexecution 
des fichiers en langage XML et les objets associes aux langages graphiques de 
description d'automatisme qui sont stockes dans les bases de donnees. Ce 

25 composant GenlnTag extrait les mots cles (elements, objets et attributs) des 
difterents fichiers de grammaire ".dtd" (402) qui definissent les grammaires XML 
pour le programme, les donnees, la configuration d'entrees-sorties en langage 
XML, afin de generer des index organises selon plusieurs fichiers, par exemple 
quatre fichiers (11,12,13,14) dans la figure 3, contenant chacun un ou plusieurs 

30 fichiers de constantes d'index utilises par les difterents gerants (Mng1,Mng2,...) 
g6rant une application. 

Le composant GenlnTag lit les fichiers de definition du type de document 
".dtd" -ou de schema M .xsd M - et g£n6re les diff6rents fichiers d'index. Dans le mode 
de realisation presente, il existe les fichiers d'index (11) pour la definition des mots- 

35 cies de la configuration materielle et logicielle (SrcTaglOConf.h, 
SrcTagLogicConf.h), les fichiers d'index (12) pour la definition des mots cies des 
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donnees et des types de donnees regroupes dans les fichiers (SrcTagDatas.h, 
SrcTagDDTSource.h, SrcTagFBSource.h), les fichiers d'index (13) pour la definition 
des mots cles pour le programme (SrcTagProgram.h, SrcTagProgramHeader.h, 
SrcTagSFCSource.h, ScrTagLDSource.h, ScrTagFBDSource.h) et les fichiers 
d'index (14) pour la definition des mots cles communs aux autres parties de 
Implication (SrcTagCommonElements.h). Ces fichiers d'index realisent la 
correspondance qui permet d'utiliser les bases de donnees (Db1, Db2,...) de 
description des applications selon I'art anterieur. lis sont stockes dans une memoire 
non volatile de la station de programrnation. 

La station de programrnation incorpore dans une memoire non volatile un 
programme gestionnaire XML Hndlr (20) -en anglais XML Handler-. Le gestionnaire 
XML Hndlr (20) est un composant logiciel developpe en langage C++, utilisable au 
travers d'une interface COM. II encapsule et utilise les services d'un analyseur Prsr 
DOM (215) -en anglais Parser DOM- et offre des services de haut niveau pour ia 
gestion de I'arborescence graphique XML (30). Le gestionnaire XMLHndlr (20), 
represente plus en detail sur la figure 4, permet de fabriquer I'arborescence (30) 
representative de I'application a partir des fichiers de description (401) en utilisant 
les fichiers de grammaire (402) ou de fabriquer cette arborescence a partir des 
20 demandes des gerants (Mng1, Mng2,...) des bases de donnees de I'application. II 
utilise les differents gerants qui appellent les services du gestionnaire XML Hndlr 
(20) en utilisant les fichiers d'index (11 a 14) generes par le composant GenlnTag 
(25). Comme represente a la figurel , chaque partie d'une application, par exemple 
programme d'application (Db1) donnees de I'application (Db2), est geree par un 
25 gerant specifique (par exemple Mng1 pour le programme d'application, Mng2 pour 
les donnees). Le gestionnaire XML Hndlr (20) comporte, en plus de I'analyseur Prsr 
DOM qui est un composant logiciel en langage C++, une routine d'exportation 
(EXP) et une routine d'importation (IMP). 

3 o La routine d'exportation (EXP) ecrit, dans un (ou plusieurs) fichier(s) de 

description XML, les donnees de I'application d'automatisme et la routine 
d'importation lit dans un (ou plusieurs) fichier(s) de description XML les donnees de 
rapplication d'automatisme. Ces routines font appel a la fois au service d'un module 
(210) de service (CsrcServices) qui lui-meme se decompose en plusieurs services. 

35 Un service (IscrWalkSource) permet le deplacement dans le fichier (401) charge en 
memoire. Le module de service (CsrcServices) comprend egalement un service 
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(IsrclmportSource) qui est un service ^initialisation de lecture d'un fichier de 
description (401), le service (IsrcexportSource) qui est un service d'ecriture de 
fichiers et le composant (IsrcPUnitService) qui permet de gerer les services 
sp6cifiques a la station de programmation. Enfin, le gestionnaire XML Hndlr (20) 
comporte un service (IsrcElement) qui est un service permettant I'acces au contenu 
d'une donn6e XML (elements et attributs). Chacun des gerants (Mng1, Mng2,...) 
dialogue avec les differents services du gestionnaire XML Hndlr (20), lis utilisent les 
fichiers index (11 £ 14) g6n6r6s par le composant GenlnTag (25) correspondant aux 
donnees de la base de donnees. 

L'application m6morisee sur la station de programmation dans un 
ensemble d'un ou plusieurs fichiers de description XML (401) est mod§lisee par le 
gestionnaire XML Hndlr (20) sous forme d'arborescence (30) en utilisant d f une part 
les informations reparties dans la mSmoire de la station de programmation dans 
des bases de donnees (Db1, Db2,...) et sous forme de fichiers binaires, et d'autre 
part les index (11 a 14) cre§s par le composant GenlnTag (25) pour acceder a ces 
informations et les representer sous forme arborescente. Le composant 
gestionnaire XML Hndlr (20), comme represents a la figure 1, communique par des 
notifications avec les grants (Mng1, Mng2,...) des bases de donnees (Db1, 
Db2,...) et avec le module de gestio'n de I'arborescence de Implication. 

Ainsi lors de la routine d'exportation, un gerant (Mng1) peut emettre une 
notification (102) «CreateNode (index, value)» demandant au gestionnaire XML 
Hndlr (20) de creer un nceud ayant un index determine et une valeur determinee. Le 
gestionnaire XML Hndlr (20), en utilisant les valeurs d'index et les fichiers de 
grammaire (402) va demander au module de gestion de I'arborescence de creer, 
par une notification (203) «CreateNode (tagname, value)», un nceud ayant pour 
nom de balise le nom defini par «tagname» et pour valeur, la valeur designee par 
«value». En sens inverse, lors de la routine dlmportation, un gerant (Mng1) 
demande au gestionnaire XML Hndlr (20) de lui envoyer les informations 
concernant un noeud par une notification (201) «GetNode (index, value)». Le 
gestionnaire XML Hndlr (20) recevant cette notification examine dans les tables de 
cprrespondance constitu6es par les fichiers d'index (11 a 14), I'index et le nom de 
balise (Tag) correspondant. Le gestionnaire XML Hndlr (20) demande alors au 
module de gestion de I'arborescence de lui envoyer une notification (302) 
«GetNode (tagname, value)». 
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Le gestionnaire (20) ainsi ctefini, permet, par son installation sur une station 
de programmation et en association avec les fichiers de grammaire (402) pour le 
langage XML, de d£crire une application d'automatisme editable par n'importe quel 
editeur (220, figure 4) car les fichiers de description XML (401) de Implication ainsi 
5 obtenus sont en ASCII et peuvent etre edites et modifies grace tout editeur de 
texte. Ceci permet d'eviter d'avoir des programmes specifiques de visualisation des 
langages graphiques specifiques aux applications d'automatisme. 

L'invention concerne aussi un equipement d'automatisme capable 

10 d'ex£cuter une application d'automatisme en langage constructeur sous la forme 
d'un fichier binaire. L'6quipement d'automatisme comprend des moyens de 
memorisation permettant de memoriser un ensemble d'un ou plusieurs fichiers de 
description d'une application d'automatisme, ces fichiers de description etant 
exprimes dans un langage textuel unique, hierarchise et orients objet. Un tel 

15 equipement d'automatisme comporte aussi des moyens de traduction, tel qu'un 
module interpreter, permettant de convertir les fichiers de description dans un ou 
plusieurs fichiers en langage binaire constructeur executable par I'equipement 
d'automatisme. Dans le mode de realisation presente, ce langage unique, 
hierarchise et oriente objet est par exemple le langage XML (extended Markup 

20 Language). Le module interpreter a pour fonction de traduire les instructions, 
decrivant une application d'automatisme, formulees en langage XML, en 
instructions executables par le systeme d'exploitation proprietaire (proprietary 
operating system) de I'equipement d'automatisme. II integre notamment un 
analyseur XML (prsr DOM) pour analyser le langage XML ainsi que des moyens de 

25 compilation. 

De cette fagon, on aboutit a un equipement d'automatisme dont le langage 
de programmation serait accessible a n'importe quel editeur disponible sur une 
machine de type PC ce qui permettrait ainsi au concepteur duplications 
d'automatisme de developper des programmes d'application dont les fichiers 

30 seraient memorises sous forme textuelle en ASCII, ceci quel que soit le 
constructeur de I'equipement d'automatisme et le systeme d'exploitation utilise, a 
condition simplement que I'equipement d'automatisme ait ete pourvu du module 
interpreter de langage XML en langage binaire proprietaire. 

Le ou les fichiers de description respectent une des grammaires de 

35 traduction en langage XML d'un ou plusieurs langages graphiques d'automatisme 
parmi le langage Ladder, le langage SFC, le langage FBD. L'equipement 
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d'automatisme comporte done egalement des moyens de verifier que, selon le 
langage graphique d'automatisme utilise, la description de ['application en langage 
XML satisfait la grammaire de description du langage graphique d'automatisme 
utilise. Pour cela, les moyens de memorisation de l'6quipement d'automatisme 
5 contiennent aussi les fichiers de grammaire (402). 

L'invention presente aussi I'avantage de permettre d'exploiter les anciens 
programmes deja developpes en convertissant (exportation) ces programmes 
formul6s dans des bases de donnees (DM, Db2,...) en fichiers XML. 
10 De plus, le gestionnaire XML Hndlr (20) presente egalement I'avantage de 

pouvoir importer un fichier de description d'une application d§veloppee en langage 
XML dans une application utilisant un des langages graphiques (LD, SFC, FBD) de 
description d'automatisme utilise jusqu'a present. 

15 Les langages graphiques peuvent ainsi etre decrits de fa$on normalisee en 

ASCII. Cette normalisation d'une grammaire permet l'6change de programmes 
d'automatismes entre logiciels (operating system) de constructeurs differents. 

La programmation en XML est independante d'une technologie graphique, 
independante de Windows, d'une librairie graphique quelconque, ou encore d'un 
20 format graphique (JPEG, BMP ...). 

L'invention permet I'echange de programmes d'application entre ateliers de 
programmation heterogenes (constructeurs differents, systemes d'exploitation 
differents,...). L'invention permet la generation de programmes d'application 
standards pouvant etre portes sur des plates-formes differentes. L'invention permet 
25 aussi la generation automatique de programmes d'application d'automatisme par 
des generateurs XML 

L'echange de donnees sous forme de fichier XML avec des logiciels de 
sch6matique electrique de type CAO, CAD, des logiciels de supervision est 
egalement facilite par l'invention. 

30 

Les annexes 4, 5, 6 d6crivent respectivement les fichiers de grammaire en 
syntaxe "Schema" (".xsd") pour la traduction en langage XML des langages : 
langage Ladder (annexe 4), langage SFC (annexe 5) et langage FBD (annexe 6). 
Ces fichiers pourraient etre utilises sur des stations de programmation exploitant ce 
35 langage ".xsd". L'homme de metier retrouvera dans ces annexes les memes objets 
et attributs que dans la syntaxe textuelle (".dtd" des annexes 1 a 3) mais ici exprime 
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dans la syntaxe schema ("xsd"). Dans ces annexes 4 a 6, la position de I'objet par 
rapport au debut de la ligne definit, par son retrait, la dependance hierarchique de 
I'objet. 

5 II doit etre evident pour les personnes versees dans I'art que la presente 

invention permet des modes de realisation sous de nombreuses autres formes 
specifiques sans I'eloigner du domaine duplication de invention comme 
revendique. Par consequent, les presents modes de realisation doivent etre 
considSres a titre d'illustration mais peuvent etre modifies dans le domaine defini 

10 par la portee des revendications jointes. 
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ANNEXE 1 

Description DTD de la orammaire du lanaaae Ladder 

5 

<!-- 

< I ENTITY % commonElements SYSTEM "commonElements .dtd u > 
%commonElements; • 

--> 

10 <! ELEMENT LDSource (networkLD , textBox* )> 

<! ATTLIST LDSource sectionSize CDATA #IMPLIED > 
< ! ELEMENT networkLD (typeLine+ , FBLink* )> 

<! ELEMENT typeLine (emptyLine | (contact | HLink | VLink | coil | control | short 
Circuit | emptyCell | calls | FFBExpression | compareBlock I operateBlock) * )> 
15 < ! ATTLIST typeLine label CDATA #IMPLIED > 
<] ELEMENT emptyLine EMPTY> 
<! ELEMENT contact EMPTY > 

< .'ATTLIST contact typeContact (openContact | 

closedContact | 
20 PContact | 

NContact ) ^REQUIRED 
contactVariableName CDATA #IMPLIED > 
<> ELEMENT HLink EMPTY > 

< ! ATTLIST HLink numberCell CDATA #IMPLIED > 
25 <! ELEMENT VLink EMPTY> 
< I ELEMENT coil EMPTY > 
<! ATTLIST coil typeCoil (coil | 

notCoil | 
setCoil j 

30 . resetCoil | 

hashCoil | 
PCoil | 

NCoil } #REQUIRED 
coilVariableName CDATA #IMPLIED > 
35 <! ELEMENT control EMPTY > 

< J ATTLIST control typeControl (jumpCoil | retCoil ) #REQUIRED 

label CDATA . #REQUIRED> 

<! ELEMENT shortCircuit (VLink , (HLink | contact | coil | calls | compareBlock ))> 

< J ELEMENT calls (instanceObj , .typeParam? , descriptionCall? )> 
40 <! ELEMENT typeParam (#PCDATA )> 

< .'ATTLIST typeParam enEnO CDATA # IMPLIED 

heightSize CDATA #IMPLIED > 
< ! ELEMENT descriptionCall (inputListFBD* , outputListFBD* )> 
< I ELEMENT inputListFBD EMPTY > 
45 < ! ATTLIST inputListFBD formal Par ameterName CDATA #IMPLIED 

ef fective Parameter CDATA #IMPLIED > 
<! ELEMENT outputListFBD EMPTY > 

<! ATTLIST outputListFBD formal ParameterName CDATA #IMPLIED 

ef fectiveParameter CDATA #IMPLIED > 
50 <! ELEMENT FBLink (objPosition , objPosition+ )> 
<! ATTLIST FBLink from CDATA # REQUIRED 

to CDATA # REQUIRED > 
< I ELEMENT compareBlock (# PCDATA )> 
<! ELEMENT FFBExpression (# PCDATA )> 
55 <! ELEMENT operateBlock (# PCDATA )> 
<! ELEMENT emptyCell EMPTY > 

< ! ATTLIST emptyCell cellNbr CDATA #IMPLIED > 
< ! ELEMENT textBox (objPosition )> 
< ! ATTLIST textBox dimH CDATA #REQUIRED 
60 dimW . CDATA #REQUIRED 

textBox NMTOKENS # IMPLIED > 



< *. i 
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ANNEXE 2 

Description DTD de la arammaire du lanaage SFC 



<!--<! ENTITY % commonEl ement s SYSTEM " commonEl ements . dtd" > 
% commonEl ements ; 
- -> 

< J ELEMENT SFCSource (SFCHeader , SFCPage )> 
<! ELEMENT SFCHeader EMPTY > 

< ! ATTLIST SFCHeader task CDATA #IMPLIED 

graphName CDATA #IMPLIED > 
15 <! ELEMENT SFCPage (networkSFC* )> 

< ! ELEMENT networkSFC ({step | jump | transition | SFCLinkObject T | commentSFC)* 
, linkSFC* )> 

<!ELEMENT step (objPosition , action* )> 
<! ATTLIST step stepName NMTOKEN #IMPLIED 
20 stepType (initialStep | step | macroStep | inStep | outstep ) 

#FIXED 'step' > 

< I ELEMENT action (actionName )> 

<! ATTLIST action qualifer {PI |N|P0|R|S|L|D|P| DS ) # REQUIRED 

tValue CDATA #IMPLIED > 
25 <! ELEMENT actionName (# PCDATA )> 
< ! ELEMENT j utnp ( ob j Pos i t ion ) > 
<! ATTLIST jump stepName CDATA #IMPLIED > 

< ! ELEMENT transition (objPosition , trans itionCondit ion? )> 
< 'ATTLIST transition trans it ionName CDATA #IMPLIED > 
30 < l ELEMENT trans itionCondit ion (transit ionName | variableTransition | 
boolLitteral ) > 

< ! ELEMENT transit ionName (# PCDATA )> 
< I ELEMENT variableTransition (#P CDATA )> 
<! ELEMENT boolLitteral EMPTY> 
35 < I ATTLIST boolLitteral boolLitteral (0 | 1 ) #IMPLIED > 
< 'ELEMENT SFCLinkObject (objPosition )> 

<! ATTLIST SFCLinkObject width CDATA #IMPLIED 

relativePos CDATA ^IMPLIED 

SFCLinkObj ectType (ABranch | PBranch [ A Joint | PJoint 

40 #REQUIRED > 

<! ELEMENT commentSFC { # PCDATA | objPosition ) *> 
< '.ATTLIST commentSFC height CDATA #IMPLIED 

width CDATA # IMPLIED > 
<! ELEMENT linkSFC (objPosition , objPosition+ )> 
45 < ! ATTLIST linkSFC typeObjectFrom (initialStep | 

step | 
macroStep | 
stepln | 
transition | 

50 ABranch | 

PBranch j 
A Joint | 

PJoint ) # REQUIRED 
typeObjectTo (initialStep | 
55 step | 

macroStep | 
stepOut | 
transition | 
ABranch | 

60 PBranch j 

A Joint | 
PJoint j 

jump ) #REQUIRED > 
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ANNEXE 3 

Description DTD de la arammaire du lanaaae FBD 

5 

<!-- <! ENTITY % commonElements SYSTEM "commonElements .dtd"> 

%commonElements; 

--> 

10 < 1 ELEMENT FBDSource (networkFBD* )> 

<! ELEMENT networkFBD ( (FFBBlock | textBoxFBD | labelObject | comment Ob j ect FBD I 
linkFBD)* , jumpObject? )> 

< I ELEMENT FFBBlock (instanceObj , typeParamFBD , objPosition , descriptionFBD? 
) > 

15 <! ELEMENT typeParamFBD (# PCDATA )> 

< IATTLIST typeParamFBD enEnO CDATA. # IMPLIED 

heightSize CDATA #IMPLIED > 
<i ELEMENT descriptionFBD (input Variable* , outputVariable* )> 
< IATTLIST descriptionFBD execOrder CDATA # IMPLIED > 
20 <! ELEMENT inputVariable EMPTY > 

< IATTLIST inputVariable formal ParameterName CDATA #IMPLIED 

effectiveParameter CDATA ^IMPLIED 
invertedPin (TRUE | FALSE ) #IMPLIED > 

< I ELEMENT outputVariable EMPTY > 
25 < IATTLIST outputVariable formal ParameterName CDATA #IMPLIED 

effectiveParameter CDATA #IMPLIED 
invertedPin (TRUE | FALSE ) # IMPLIED > 

< ! ELEMENT labelObject (objPosition )> 
< IATTLIST labelObject label CDATA #IMPLIED > 
30 <! ELEMENT jumpObject (objPosition )> 

< IATTLIST jumpObject label CDATA ^IMPLIED > 
< ! ELEMENT textBoxFBD (#PCDATA | objPosition )*> 
< IATTLIST textBoxFBD width CDATA #IMPLIED 

height CDATA #IMPLIED > 
35 < I ELEMENT comment Object FBD (#P CDATA | objPosition )*> 

< 'ELEMENT linkFBD (objPosition , objPosition , objPosition* )> 
< IATTLIST linkFBD origineLink CDATA #IMPLIED 

destinationLink CDATA , # IMPLIED > 
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ANNEXE 4 

Description Schema de la arammaire du lanaaae Ladder 

<?xml version = "1.0" encoding * "UTF-8"?> 
5 <! --Generated by XML Authority. Conforms to w3c http://www.w3.org/2000/10/XMLSchema 

<xsd:schema xmlns.-xsd = "http: //www. w3 .org/ 2000/ 10/XMLSchema"> 
<!--<xsd: include schemaLocation * "commonElements.xsd"/>--> 
<xsd: element name * n LDSource"> 
10 <xsd: complexType* 

<xsd: sequence > 

<xsd: element ref = "networkLD"/> 

<xsd:element ref = "textBox" minOccurs = "0" maxOccurs = "unbounded"/> 
</xsd: sequence > 

15 <xsd: attribute name = "nbColumns" type * "xsd: string "/> 

</xsd: complexType> 
</xsd : element > 

<xsd: element name = "networkLD"> 
<xsd : complexType> 
20 <xsd: sequence > 

<xsd:element ref = "typeLine" maxOccurs = "unbounded" /> 
<xsd:element ref = "FBLink" minOccurs = "0" maxOccurs » "unbounded"/> 
</xsd: sequence> 
< /xsd : compl exType > 
25 < /xsd : e 1 ement > 

<xsd: element name « "typeLine"> 
<xsd : complexType > 
<xsd:choice> 

<xsd:element ref - "emptyLine"/> 
30 <xsd: choice minOccurs = "0" maxOccurs = "unbounded" > 



35 



<XSd: 


element 


ref 




"contact"/> 


<XSd: 


element 


ref 




"HLink"/> 


<xsd: 


element 


ref 




«VLink"/> 


<xsd : 


element 


ref 




"coil"/> 


<xsd: 


element 


ref 




i " control "/> 


<XSd: 


element 


ref 




" shortCircuit ■ / > 


<XSd : 


element 


ref 




"emptyCell"/> 


<XSd: 


element 


ref 




"calls"/> 


<XSd: 


element 


ref 




" FFBExpress ion" / > 


<XSd: 


element 


ref 




" compareBl ock " / > 


<XSd: 


element 


ref 




" ope rat eBl ock " / > 
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</xsd: choice> 
</xsd:choice> 

<xsd: attribute name = "label" type « "xsd: string" /> 
45 < /xsd: complexType > 

< /xsd: el ement > 

<xsd: element name "emptyLine"> 
<xsd : complexType > 
<xsd: sequence /> 
50 < /xsd: complexType > 

< /xsd: element > 

<xsd: element name =» " contact "> 
<xsd : complexType > 
<xsd: sequence / > 

55 <xsd: attribute name = "typeContact" use = "required" > 

<xsd: simpleType> 

<xsd: restriction base « "xsd:NMTOKEN" > 

<xsd: enumeration value = "openContact"/> 
<xsd: enumeration value = "closedContact "/> 
60 <xsd: enumeration value = "PContact"/> 

<xsd: enumeration value = "NContact"/> 
</xsd : restrict ion> 
< /xsd : s impl eType > 
</xsd:attribute> 

65 <xsd: attribute name = "contactVariableName" type = "xsd: string" /> 

< /xsd : complexType > 
</xsd: element > 

<xsd: element name = "HLink"> 
<xsd : complexType > 
70 <xsd: sequence/ > 
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<xsd: attribute name = "numberCell" use = "required" type =. "xsd: string "/> 
</xsd: complexType> 
</xsd:element> 

<xsd: element name = "VLink"> 
5 <xsd: complexType> 

<xsd : sequence/ > 
</xsd: complexType> 
</xsd:element> 
<xsd: element name = "coil"> 
10 <xsd:complexType> 
<xsd: sequence/ > 

<xsd: attribute name = "typeCoil" use « "required" > 
<xsd : s impleType > 

<xsd: restriction base ■ "xsd : NMTOKEN" > 
15 <xsd: enumeration value « »coil"/> 

<xsd: enumeration value = n notCoil"/> 
<xsd: enumeration value = "setCoil"/> 
<xsd: enumeration value ■ n resetCoil"/> 
<xsd: enumeration value ■ "hashCoil"/> 
20 <xsd: enumeration value s "PCoil"/> 

<xsd: enumeration value ■ "NCoil"/> 
</xsd: restriction 
< /xsd : s impl eType > 
</xsd : attribute> 

25 <xsd: attribute name = "coilVariableName" type = "xsd: string "/> 

</xsd: complexType> 
</xsd:element> 

<xsd: element name ■ " control "> 
<xsd:complexType> 
30 <xsd: sequence /> 

<xsd: attribute name « "typeControl" use = " required" > 
<xsd:s impleType > 

<xsd: restrict ion base = "xsd: NMTOKEN" > 
<xsd: enumeration value a " jumpCoil"/> 
35 <xsd: enumeration value » " ret Coil"/ > 

</xsd : restriction 
< /xsd : s impl eType > 
</xsd : attribute> 

<xsd: attribute name = "label" type = "xsd: string"/> 
40 </xsd:complexType> 
</xsd: element > 

<xsd: element name = "shortCircuit"> 
<xsd : complexType> 
<xsd : sequence > 
45 <xsd: element ref = "VLink"/> 

<xsd:choice> 

<xsd: element ref = "HLink"/> 
<xsd: element ref « "contact "/> 
<xsd: element ref = "coil"/> 
50 <xsd: element ref « "calls" /> 

<xsd: element ref = "compareBlock"/> 
</xsd:choice> 
< /xsd : sequence > 
</xsd: complexType> 
55 </xsd: element > 

<xsd: element name = "calls" > 
<xsd : complexType> 
<xsd : sequence > 

<xsd:element ref « "instanceObj "/> 
60 <xsd: element ref = "typeParam" minOccurs = "0"/> 

<xsd:element ref = "descriptionCall" minOccurs = "0"/> 
</xsd: sequence > 
</xsd : complexType> 
< /xsd: element > 
65 <xsd: element name e "typeParam" > 

<xsd : complexType> 

<xsd : simpleContent > 

<xsd: extension base = "xsd: string "> 

<xsd: attribute name = "enEnO" type = "xsd: string" /> 
70 <xsd: attribute name - "heightsize" type = "xsd: string" /> 

</xsd:extension> 
< /xsd :s impl eContent > 
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< /x sd : c omp 1 exTyp e > 
</xsd: element > 

<xsd: element name = "descriptionCall"> 
<xsd: complexType> 
5 <xsd: sequence > 

<xsd: element ref = "input Li stFBD" minOccurs^" 0 "maxOc cur s= "unbounded" /> 
<xsd: element ref » "outputListFBD ,, minOccurs= M 0"maxOccurs= "unbounded" /> 
</xsd: sequence> 
</xsd: complexType> 
10 </xsd:element> 

<xsd: element name - "inputListFBD"> 
<xsd : complexType> 
<xsd: sequence/ > 

<xsd: attribute name = "formalParameterName" type = "xsd: string"/> 
15 <xsd: attribute name - "ef f ectiveParameter" type = "xsd: string" /> 

</xsd : complexType> 
< /xsd : e 1 ement > 

<xsd: element name = "outputListFBD"> 
<xsd : complexType> 
20 <xsd: sequence/ > 

<xsd: attribute name « "formalParameterName" type =» "xsd: string"/> 
<xsd: attribute name = "eff ectiveParameter" type - "xsd: string" /> 
< /xsd : complexType > 
</xsd : el ement > 
25 <xsd: element name ~ "FBLink"> 

<xsd : complexType > 
<xsd: sequence > 

<xsd: element ref = n objPosition"/> 

<xsd: element ref • "obj Posit ion" maxOccurs = "unbounded" /> 
30 < /xsd: sequence > 

<xsd: attribute name = "from" use ~ "required" type = "xsd: string" /> 
<xsd: attribute name = "to" use = "required" type ~ "xsd: string" /> 
< /xs d : comp lexType > 
< /xsd : e 1 ement > 

35 <xsd: element name = "compareBlock" type = "xsd: string" /> 

<xsd: element name ■ " FFBExpress'ion" type = "xsd: string" /> 
<xsd: element name = "operateBlock" type = "xsd: string" /> 
<xsd: element name = "empty Cell "> 
<xsd : complexType > 
40 <xsd: sequence/ > 

<xsd: attribute name = "cellNbr" use « "required" type = "xsd: string" /> 
< /xsd : complexType > 
</xsd : element > 

<xsd: element name = "textBox"> 
45 <xsd: complexType > 

<xsd: sequence > 

<xsd: element ref = "obj Posit ion" /> 
</xsd : sequence> 

<xsd: attribute name = "dimH" use = "required" type « "xsd: string"/> 
50 <xsd: attribute name - "dimW" use - "required" type = "xsd: string" /> 

<xsd: attribute name - "textBox" type » "xsd:NMTOKENS"/> 
</xsd : complexType > 
</xsd : element> 
</xsd : schema? 
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ANNEXE 5 

Description Schema de la gram ma ire du lanaaae SFC 

<?xml version = "1.0" encoding = "UTF-8"?> 

<! --Generated by XML Authority. Conforms to w3c 

http://www.w3 .org/2 000/ 10/XMLSchema--> 

<xsd:schema xmlnsrxsd = "http://www.w3.org/2000/10/XMLScheTna"> 
<! --<xsd: include schemaLocation « "commonElements.xsd"/>--> 
<xsd: element name = "SFCSource n > 
<xsd : complexType> 
<xsd: sequence > 

<xsd: element ref » "SFCHeader"/> 
<xsd: element ref s "SFCPage"/> 
</xsd: sequence > 
</xsd : complexType> 
</xsd: element > 

<xsd: element name « "SFCHeader"> 
<xsd : complexType > 
<xsd: sequence/ > 

<xsd: attribute name = "task" type = "xsd: string" /> 
<xsd: attribute name « "graphName" type » "xsd: string" /> 
</xsd : complexType > 
</xsd:element> 

<xsd: element name = "SFCPage"> 
<xsd : c omp 1 exType > 
<xsd : sequence> 

<xsd: element ref « "networkSFC" minOccurs = "0" maxOccurs =" unbounded"/ 
</xsd: sequence > 
< /xsd : complexType > 
</xsd: element > 

<xsd: element name = "networkSFC" > 
<xsd : complexType > 
<xsd: sequence > 

<xsd: choice minOccurs = "0" maxOccurs ■ "unbounded" > 
<xsd:element ref = "step"/> 
<xsd: element ref = "jump"/> 
<xsd: element ref = "transition" /> 
<xsd:element ref « "SFCLink0bject*7> 
<xsd: element ref - "commentSFC"/> 
</xsd: choice > 

<xsd:element ref = "linkSFC" minOccurs » "0" maxOccurs = "unbounded" /> 
</xsd:element> 
</xsd : complexType > 
</xsd: element > 
<xsd: element name = "step"> 
<xsd : complexType > 
<xsd : sequence> 

<xsd: element ref « "obj Position" /> 

<xsd:element ref = "action" minOccurs ■ "0" maxOccurs = "unbounded"/> 
</xsd: sequence > 

<xsd: attribute name ■ "stepName" type = "xsd:NMTOKEN"/> 
<xsd: attribute name =* "stepType" use = "fixed" value = "step"> 
<xsd: simpleType> 

<xsd: restriction base « "xsd : NMTOKEN" > 

<xsd: enumeration value » "initialStep"/> 
<xsd: enumeration value ■ "step"/> 
<xsd: enumeration value = "macroStep"/> 
<xsd: enumeration value - "inStep"/> 
<xsd: enumeration value = "outStep"/> 
</xsd: restrict ion> 
</xsd: simpleType> 
</xsd:attribute> 
</xsd : complexType> 
< /xsd: element > 

<xsd: element name = "action" > 
<xs d : c omp 1 exTyp e > 
<xsd: sequence > 

<xsd: element ref =» "actionName"/> 
< /xsd : s equence > 

<xsd: attribute name = "qualifer" use = "required"> 
<xsd: simpleType> 
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</xsd : restriction> 
</xsd: simpleType> 
</xsd:attribute> 

<xsd: attribute name = "tValue" type = "xsd: string" /> 
< / xs d : c omp 1 exTyp e > 
< /xsd : element > 

<xsd: element name = "actionName" type = "xsd: string" /> 
<xsd: element name = M jump"> 
<xsd : complexType> 
<xsd : sequence> 

<xsd: element ref - " obj Posit ion" /> 
< /xsd: sequence > 

<xsd: attribute name * "stepName" type = "xsd: string"/> 
< /xsd: comp 1 exType > 
</xsd: element > 

<xsd: element name = "transition" > 
<xsd : complexType> 
<xsd: sequence > 

<xsd: element ref = "obj Posit ion" /> 

<xsd: element ref = u trans itionCondit ion" minOccurs » M 0"/> 
</xsd: sequence> 

<xsd: attribute name - "trans it ionName" type = "xsd: string" /> 
< /xsd : complexType> 
</xsd : element > 

<xsd: element name " transit ionCondition"> 
<xsd : complexType> 
<xsd:choice> 

<xsd: element ref = "transit ionName "/> 
<xsd: element ref = "variableTransition"/> 
<xsd: element ref ■ "boolLitteral"/> 
</xsd: choice > 
</xsd: complexType> 
</xsd: element > 

<xsd: element name = "transitionName" type = "xsd: string"/ > 
<xsd:element name = "variableTransition" type = "xsd: string "/> 
<xsd: element name * "boolIiitteral"> 
<xsd: complexType> 
<xsd: sequence/ > 

<xsd: attribute name - "boolLitteral" > 
<xsd: simpleType> 

<xsd: restriction base = "xsd : NMTOKEN" > 
<xsd: enumeration value = "0"/> 
<xsd: enumeration value « "l"/> 
</xsd: restriction 
</xsd: simpleType> 
</xsd : attribute> 
< / xs d : comp 1 exType > 
</xsd: element> 

<xsd: element name = "SFCLinkObject "> 
<xsd :complexType> 
<xsd : sequence > 

<xsd: element ref = "obj Posit ion" /> 
< /xsd : sequence > 

<xsd: attribute name = "width" type = "xsd: string" /> 
<xsd: attribute name = "relativePos" type = "xsd: string"/> 
<xsd: attribute name « "SFCLinkObjectType" use = " required" > 
<xsd : s impleType > 

<xsd: restriction base = "xsd : NMTOKEN" > 
<xsd: enumeration value = "ABranch"/> 
<xsd: enumeration value = "PBranch M /> 
<xsd: enumeration value * "AJoint"/> 
<xsd: enumeration value = " P Joint "/> 
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</xsd: restriction 
</xsd:simpleType> 
</xsd:attribute> 
</xsd:complexType> 
</xsd:element> 

<xsd: element name o " comment SFC"> 
<xsd:complexType mixed = "true"> 

<xsd:choice minOccurs = "0" maxOccurs = "unbounded" > 

<xsd: element ref o "obj Posit ion"/> 
</xsd:choice> 

<xsd: attribute name = "height" type = "xsd:string"/> 
<xsd: attribute name = "width" type « "xsd: string 11 /> 
</xsd: complexType> 
< /xsd: element > 

<xsd: element name = "linkSFC"> 
<xsd : complexType > 
<xsd: sequence > 

<xsd: element ref = "obj Position" /> 

<xsd: element ref = "obj Position" maxOccurs = "unbounded"/ 
</xsd : sequence> 

<xsd: attribute name = "typeObjectFrom" use = "required" > 
<xsd : s impleType > 

<xsd: restriction base = "xsd : NMTOKEN" > 

<xsd: enumeration value = "initialStep"/> 
<xsd: enumeration value = "step"/> 
<xsd: enumeration value « "macroStep"/> 
<xsd: enumeration value * "stepIn"/> 
<xsd: enumeration value - "transition"/> 
<xsd: enumeration value = "ABranch"/> 
<xsd: enumeration value = "PBranch"/> 
<xsd: enumeration value = "AJoint"/> 
<xsd: enumeration value ■ "PJoint"/> 
</xsd:restriction> 
</xsd:simpleType> 
</xsd : attribute> 

<xsd: attribute name « "typeObjectTo" use = "required" > 
<xsd : s impl eType > 

<xsd: restriction base = "xsd: NMTOKEN" > 

<xsd: enumeration value = "initialStep H /> 
<xsd: enumeration value = "step"/> 
<xsd: enumeration value ■ "macroStep"/> 
<xsd: enumeration value s M stepOut"/> 
<xsd: enumeration value = "transition" /> 
<xsd: enumeration value = "ABranch"/> 
<xsd: enumeration value = "PBranch"/> 
<xsd: enumeration value = "AJoint"/> 
<xsd: enumeration value = "PJoint"/> 
<xsd: enumeration value ■ "jump ,, /> 
</xsd: restriction 
< /xsd :s impleType > 
</xsd:attribute> 
</xsd : complexType> 
</xsd:element> 
/xsd: schema > 
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ANNEXE 6 

Description Schema de la grammajrg du lanqaae FBD 

5 <?xml version a "1.0" encoding = "UTF-8"?> 

<! --Generated by XML Authority. Conforms to w3c http://www.w3.org/2000/10/XMLSchema-- 
> 

<xsd:schema xmlnsrxsd a "http://www.w3 .org/ 2000/ l0/XMLSchema"> 
<! --<xsd: include schemaLocation = "commonElements .xsd"/>--> 
10 <xsd: element name - "FBDSource"> 

<xsd: complexType> 
<xsd: sequence > 

<xsd: element ref a "networkFBD" maxOccurs a "unbounded" /> 
< /xsd : sequence > 
15 < /xsd : complexType > 

</xsd: element > 

<xsd: element name = "networkFBD" > 
<xsd: complexType > 
< /xsd : sequence > 

20 <xsd: choice minOccurs = "0" maxOccurs a "unbounded" > 

<xsd: element ref = ,, FFBBlock"/> 

<xsd: element ref = w textBoxFBD"/> 

<xsd: element ref = "label Ob ject"/> 

<xsd: element ref a "comment Object FBD"/ > 
25 <xsd: element ref = "linkFBD"/> 

</xsd: choice > 

<xsd: element ref « " jumpObject" minOccurs = "0"/> 
< /xsd: sequence > 
< /xs d : c omp 1 exType > 
30 </xsd: element> 

<xsd: element name = "FFBBlock"> 
<xsd : complexType > 
<xsd: sequence > 

<xsd: element ref = "instanceObj "/> 
35 <xsd: element ref = "typeParamFBD"/> 

<xsd: element ref = "obj Posit ion" /> 

<xsd: element ref = "descriptionFBD" minOccurs = "0"/> 
</xsd: sequence> 

< /xsd : complexType > 
40 </xsd:element> 

<xsd: element name ~ " type Par amFBD " > 
<xsd : compl exType > 

<xsd:simpleContent> 

<xsd: extension base = "xsd: string" > 
45 <xsd: attribute name = "enEnO" type « "xsd: string" /> 

<xsd: attribute name « "heightSize" type « "xsd: string" /> 
< /xsd : extens ion> 
</xsd: simpleContent> 
</xsd: compl exType > 
50 </xsd: element > 

<xsd: element name a "descriptionFBD" > 
<xsd : compl exType > 
<xsd : sequence > 

<xsd: element ref » "input Variable" minOccurs = "0 "maxOccurs = "unbounded" /> 
55 <xsd: element ref = "outputVariable" minOccurs = " 0 w maxOccurs= "unbounded" / > 

</xsd: sequence > 

<xsd: attribute name = 11 execOrder " type = "xsd: string"/> 

< /xsd : complexType > 
</xsd: element > 

60 <xsd: element name = " input Variable "> 

<xsd: complexType> 
<xsd : sequence/ > 

<xsd: attribute name = "f ormalParameterName" type = "xsd: string" /> 
<xsd: attribute name = "ef fectiveParameter" type - "xsd: string" /> 
65 <xsd: attribute name =* "invertedPin"> 

<xsd : simpleType> 

<xsd: restriction base a "xsd:NMTOKEN" > 
<xsd: enumeration value = "TRUE"/> 
<xsd: enumeration value a "FALSE" /> 
70 </xsd: restriction> 

</xsd: simpleType> 
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</xsd : attribute> 
< /xsd : comp 1 exType > 
</xsd: element > 

<xsd: element name =» "outputVariable"> 
<xsd : complexType> 
<xsd : sequence/ > 

<xsd: attribute name = "formalParameterName" type ■ "xsd: string" /> 
<xsd: attribute name = "ef f ectiveParameter" -type = "xsd: string "/> 
<xsd: attribute name = "invertedPin"> . 
<xsd: simpleType> 

<xsd: restriction base = " xsd : NMTOKEN" > 
<xsd: enumeration value ■ "TRUE"/> 
<xsd: enumeration value = "FALSE" /> 
</xsd : restrict ion> 
< / xsd : s imp 1 eType > 
</xsd:attribute> 
< /xsd : comp lexType> 
</xsd:element> 

<xsd: element name = "labelObject"> 
<xsd : complexType> 
<xsd : sequence > 

<xsd: element ref = "obj Posit ion" /> 
</xsd : sequence > 

<xsd: attribute name = "label" type = "xsd: string" /> 
< /xsd : complexType > 
</xsd: element> 

<xsd: element name ■ " jumpObject"> 
<xsd : complexType > 
<xsd: sequence > 

<xsd: element ref - " obj Posit ion "/> 
</xsd: sequence > 

<xsd: attribute name * "label" type = "xsd: string"/ > 
< / x s d : compl exTyp e > 
< /xsd: element > 

<xsd: element name s "textBoxFBD"> 
<xsd: complexType mixed * "true"> 

<xsd:choice minOccurs = "0" maxOccurs - "unbounded" > 

<xsd: element ref = "objPosition"/> 
</xsd: choice > 

<xsd: attribute name = "width" type = "xsd: string" /> 
<xsd: attribute name = "height" type = "xsd: string" /> 
< /xsd : complexType > 
</xsd:element> 

<xsd: element name = " comment Ob jectFBD" > 
<xsd: complexType mixed =» "true"> 

<xsd: choice minOccurs = "0" maxOccurs = "unbounded" > 

<xsd: element ref = "objPosition"/> 
</xsd:choice> 
</xsd: complexType > 
</xsd: element> 

<xsd: element name = "linkFBD"> 
<xsd : complexType > 
<xsd:sequence> 

<xsd: element ref «= "obj Posit ion" /> 
<xsd: element ref = " obj Posit ion" /> 

<xsd:element ref = "obj Posit ion" minOccurs = "0" maxOccurs=" unbounded"/ 
< /xsd : sequence > 

<xsd: attribute name « "origineLink" type = "xsd: string" /> 
<xsd: attribute name = "destinationLink" type = "xsd: string"/> 
< /xsd : compl exType > 
< /xsd: element > 
</xsd:schema> 
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REVEND1CATIONS 



1. Station de programmation d'une application d'automatisme destinee a 
5 etre executee dans un §quipement d'automatisme, caracterisee en ce qu'elle 
memorise dans une memoire interne au moins un fichier de grammaire (402) en 
format textuel contenant une grammaire de description des applications 
d'automatisme, pour au moins un des langages graphiques d'automatisme (Ladder, 
SFC, FBD) selon un langage unique, hierarchise et oriente objet. 

10 2. Station de programmation selon la revendication 1, caracterisee en ce 

que la memoire contient egalement un ensemble d'un ou plusieurs fichiers de 
description (401), chaque fichier de description decrivant une partie de I'application 
d'automatisme et etant exprime dans le langage unique, hierarchise et oriente objet. 

3. Station de programmation selon la revendication 2, caracterisee en ce 
15 que le langage unique, hierarchise et oriente objet est le langage XML (extended 

Markup Language). 

4. Station de programmation selon la revendication 2, caracterisee en ce 
que I'ensemble des fichiers de description (401) de I'application contient un fichier 
de description du programme d'application, un fichier de description des entrees- 

20 sorties de I'application et un fichier de description des donnees de I'application. 

5. Station de programmation selon la revendication 2, caracterisee en ce 
qu'un fichier de grammaire (LD_Source.*) decrit une application en langage Ladder 
en definissant les differents elements du langage Ladder comme des objets, 
chacun de ces elements comprenant des attributs soit sous forme d'objets, de 

25 parametres, de variables ou de textes et constituant des informations memorisees 
dans la memoire interne de la station de programmation et representables sous 
forme d'arborescence. 

6. Station de programmation selon la revendication 5, caracterisee en ce 
que les differents elements du langage Ladder comprennent un contact, un lien 

30 horizontal, un lien vertical, une bobine, un court-circuit, une cellule vide, un appel de 
bloc fonction, une expression FFB, un bloc de comparaison, un bloc d'operations 
arithmetiques. 

7. Station de programmation selon la revendication 2, caracterisee en ce 
qu'un fichier de grammaire (SFCJSource.*) decrit une application en langage SFC 
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en d6finissant comme des objets les differents elements du langage SFC, a savoir 
une 6tape, une transition, un saut, un lien entre graphe, un commentaire, les 
coordonnees graphiques des differents elements de type saut, 6tape ou transition 
etant definies par un objet de type position definissant les coordonnees de position 
de I'objet respectif dans la grille de lignes et de colonnes de representation du 
graphique de I'objet sur des moyens de visualisation de la station de 
programmation. 

8. Station de programmation selon la revendication 2, caracterisee en ce 
qu'un fichier grammaire (FBD Source.*) decrit une application en langage FBD en 
d§finissant les differents elements du langage FBD comme des objets. 

9. Station de programmation selon la revendication 8, caracteris£e en ce 
que les differents elements du langage FBD comprennent des blocs fonctions, des 
boTtes de texte, des liens entre blocs, des instructions de saut, des labels et des 
commentaires. 

10. Station de programmation selon Tune des revendications 
precedentes, caracterisee en ce qu'elle incorpore, dans une memoire non volatile, 
un gestionnaire XML Hndlr (20) dialoguant par des notifications, d'une part avec un 
module de gestion de I'arborescence (30) representative de Implication 
d'automatisme exprimee dans le langage unique, hierarchise et oriente objet et 
d'autre part avec une pluralite de gerants (Mng1,Mng2,...) de bases de donnees, 
chaque gerant etant specifique & une partie de Tapplication d'automatisme 
memorisee dans une des bases de donnees (Db1, Db2,...). 

11. Equipement d'automatisme capable d'executer une application 
d'automatisme, caracterise en ce qu'il comprend des moyens de memorisation pour 
memoriser un ensemble d'un ou plusieurs fichiers de description (401) de 
Implication d'automatisme exprim6s dans un langage unique, hierarchise et oriente 
objet, I'equipement d'automatisme comportant egalement des moyens de traduction 
permettant de convertir les fichiers de description dans un langage binaire 
executable par l'6quipement d'automatisme. 

12. Equipement d'automatisme selon la revendication 11, caracterise en 
ce que le langage unique, hi6rarchis§ et oriente objet est le langage XML (extended 
Markup Language). 

13. Equipement d'automatisme selon la revendication 12, caracteris6e 
en ce que ('ensemble des fichiers de description de ['application contient un fichier 
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de description du programme duplication, un fichier de description des entrees- 
sorties de 1'application et un fichier de description des donnees de I'application. 

14. Equipement d'automatisme selon la revendication 12, caracterise en 
ce que le ou les fichiers de description respectent une des grammaires de 

5 traduction en langage XML d'un ou plusieurs langages graphiques d'automatisme. 

15. Equipement d'automatisme selon la revendication 14, caracterise en 
ce que I'equipement d'automatisme comporte des moyens de verifier que, selon le 
langage graphique d'automatisme utilise, la description de ('application en langage 
XML satisfait la grammaire de description du langage graphique d'automatisme 

10 utilise. 

16. Equipement d'automatisme selon la revendication 14, caracterise en 
ce que le langage graphique d'automatisme utilise comprend un ou plusieurs 
langages parmi le langage Ladder, le langage SFC et le langage FBD. 
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